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Abstract. The actor model eases the definition of concurrent programs with non 
uniform behaviors. Static analysis of such a model was previously done in a data- 
flow oriented way, with type systems. This approach was based on constraint set 
resolution and was not able to deal with precise properties for communications of 
behaviors. We present here a new approach, control-flow oriented, based on the 
abstract interpretation framework, able to deal with communication of behaviors. 
Within our new analyses, we are able to verify most of the previous properties we 
observed as well as new ones, principally based on occurrence counting. 

1 Introduction 

1.1 Context - Motivation 

The development of the telecommunication industry and the generalization of network 
use bring concuiTent and distributed programming in the limelight. In that context, pro- 
gramming is a hard task and, generally, the resulting applications contain much more 
bugs than usual centralized software. As sequential object oriented programming is 
commonly accepted as a good way to build software, concuiTent object oriented pro- 
gramming seems to be well-suited for programming distributed systems. Since non- 
determinism resulting from network communications makes it difficult to validate any 
distributed functionality using informal approaches, our work is focused on applying 
formal methods to improve concurrent object oriented programming. 

To obtain widely usable tools, we have chosen to use the actor model proposed by 
Hewitt [19] and developed by Agha [1]. This model is based on a network of au- 
tonomous and cooperative agents (called actors), which encapsulate data and programs, 
communicating using an asynchronous point to point protocol. An actor stores each 
received message in a queue and when idle, processes the first message it can handle 
in this queue. Besides those conventions (which are also true for concuiTent objects), 
an actor can dynamically change its interface. This property allows to increase or de- 
crease the set of messages an actor may handle, yielding a more accurate programming 
model. This model, also known as concurrent objects with non uniform behavior (or 
interface), has been adopted by the telecommunication industry for the development of 
distributed and concurrent applications for the Open Distributed Computing framework 
(ITU X901-X904) and the Object Description Language (TINA-C extension of OMG 
IDL with multiple interfaces). Until now, we have been designing several analyses for 
an actor model, all of which based on typing systems. Our main objective was, and still 



is, to detect in a most accurate way typical flaws of distributed applications, like for 
instance communication deadlock or non linearity (i.e. the fact that several distributed 
actors have the same address). Due to Umitations of our previous attempts, which we 
could somehow overcome but at the price of a much greater complexity unmatched with 
only a small gain in precision, we decided to move to the framework of abstract inter- 
pretation, whose tools and ideas have now significantly grown in maturity and are being 
widely used in industrial contexts, or are on the verge of being so. We now investigate 
these techniques in order to capture our long standing properties of interest (detection 
of orphan messages, that is messages sent to an actor which will not handled them) as 
well as new ones, especially dedicated to control of resources' usage. 

In a first section, we define our actor calculus. Then in the second part, we introduce 
our non standard semantics upon which we define, in the third part, an abstraction. 
FinaUy, in the last part, we explain how to use the abstraction to observe properties 
about an analyzed term. 

1.2 Related works 

Concerning concurrent objects and actors with uniform or non-uniform behaviors, and 
more generally process calculi, typing systems (usually related to data-flow like anal- 
ysis) have been the subject of active research. Two opposite approaches have been fol- 
lowed: type declaration and type inference. In the first case, most proposals make use 
of types as processes of a simple algebra, for instance CCS (Calculus of Communi- 
cating Systems) processes. This allows a form of subtyping through simulation rela- 
tions or language containment. The works of KOBAYASHI et al. [20,22], Ravara et 
al. [28], Najm et al. [4,23], Puntigam [26], and Hennessy et al. [18] foUow this 
line of thought, to which we can add the works of Rajamani et al. [5,27], bringing 
model-checking issues for those processes-as-types in the scope. The second case is 
again twofold: on one side we have unification based typing algorithms focusing on re- 
sources' usage control witnessed by the works of FOURNET et al. [16] and BOUDOL et 
al. [3], whereas on the other side we have flow based algorithms, related to behavior and 
communication patterns reconstruction, advocated by the works of Nielson et al. [2] 
and Pantel et al. [6,8,9]. Explicit typing may provide more precise information but 
are sometimes very hard to write for the programmer (they might be much more com- 
plex than the program itself). ImpUcit typing requires less user supplied information but 
lead to less precise results. 

One drawback of type-based analyses is that they are mainly concerned with data- 
flow analyses (as types basicaUy represent sets of possible values for variables). In 
this context, control flow analyses can be mimicked with sophisticated encodings [24] 
but abstract interpretation seems to be more adequate in this respect. It has been re- 
cently applied with success to concurrent and distributed programming by the work of 
Venet [29] and later Feret [14,15]. 

2 CAP: a primitive actor calculus 

In order to ease the definition of static analysis for actor based programming, we pro- 
posed, in 96, the CAP primitive actor calculus [7], which merge asynchronous 7t-calculus 



and Cardelli's Primitive Object Calculus. The following example illustrates both 
rephcation and behavior passing mechanisms of CAP. The v operator defines two ad- 
dresses, a and b, then two actors denoted by program points 1 and 7 are defined on those 
addresses with the behavior set respectively denoted by 2 and 4 for a and 8 for b. 

At this point the actor 1 can handle messages called m or send when b can only 
handle beh messages. 

Va«,feP, a D>1 [m2() = ^e,s){a s), 

send^{x) = <^ beh{s))] 

II a<^send{b) 

\\ b>'' [beh^{x)=^{e,s){e\>'^x)] 
II /7<i"m() 

There are also two messages in the initial configuration. One is labeled send and is sent 
to a, the other one is labeled m and is sent to b. In the initial configuration, there is only 
one possible interaction, in which the actor a handles the message send. The message m 
is an orphan one: it is in the configuration but cannot be handled for the moment. After 
one interaction between a and the message send, the message beh which argument is 
the behavior's set of a is sent to b. Thus b can handle that message. In its continuation, 
the actor b assumes the behavior's set of a. Thus b can now handle the message m. This 
example shows how to send a behavior to another actor. Such a mechanism increases 
the difficulty of statically inferring properties. Stuck-freeness, i.e. the detection of the 
set of permanent orphans messages, or hnearity, i.e. verifying that at most one actor is 
associated to a particular address at the same time, are harder to statically infer when 
we allow behavior passing. This point was one of the constraints which led us to switch 
from type based analysis to abstract interpretation. 

2.1 Syntax and semantics 

Let ^ be an infinite set of actor names, 1^ be an infinite set of variables. Let be 

a set of message labels, J^fp be the set of program point labels and ^„ be the set of 
name labels. In the following, we denote U ^„ by The syntax of configurations 
is described as follows: 

C::=0 I va«C I C||C I a>'P I a<'m{P) 
P::=x I [m'iiV^r) = ^(e,i)c/"^'""] 

Configurations can be an empty process, a creation of actor's address, parallel execu- 
tion, an actor on address a with behavior defined by P and, finally, a message sent to 
an address a with arguments P. Program points define messages, behaviors' installation 
or external choices between some actors' behaviors. They will be used to build traces 
of the execution control flow. Name restriction, in the configuration (va")C, acts as a 
name binder, so does the C, operator and the message label for variables in the behavior 

description of an actor, i.e. in the behavior [m\'{xi) = ^(e/,5',)C; ] , therefore the oc- 
currences of a in C, Xi in ^(e,,.s,)C, and e, and Si in C, are bound. The ^ operator is our 
reflexivity operator, it catches both address and behavior of its actor and allows to re-use 
them in the behavior. We denote hy f 9i (C) the set of free names in C and by ^ (C) 



the set of free variables. The standard semantics of CAP was defined, a la Milner, by 
both the usual transition rule (c/ Fig. 1) and the congruence relation (c/ Fig. 2). 



T = [mi{xi) = t,{ei,Si)Ci 




length{Ti) = length{xk), 
k€[i,...,n\ 



a > r II a <' 



l' rn{Ti) 



comm(/,;j) 



Ck[ek ^a,Sk^ T,Xk <- 7]] 



In order to distinguish transitions, we label the interacting parts of terms. Here the message has 
label / and the matching behavior label 1^. 



3 Non standard semantics 

In order to ease the definition of abstract interpretations, we need to define define, in this 
section, another semantics for CAP and prove it bisimilar to standard CAP semantics. 
The non standard semantics allows us to label each process with the history of transi- 
tions which led to both its creation and the creation of its values. Our work is based on 
a generic non standard semantics which has been defined by Feret [14,15] to model 
first order process calculi as Jt-calculus, spi-calculus, Ambients, Bio-ambients calculus. 
We also describe in this section how we adapt this general framework to express the 
CAP language which has a notion of higher order due to its behavior passing and re- 
flexivity mechanism operator). We then briefly describe the operational semantics of 
the generic non standard semantics. 

A configuration of a system, in this semantics, is a set of threads. Each thread f is a 
triple defined as / = {p, id,E) e x ^ x {Y i-^ x ^)) where p is the program 
point representing the thread in the CAP term, id is the history marker, also called 
its identity, and E its environment. This environment is a partial map from a variable 
to a pair {value, marker). Each marker is a word on program points representing the 
history of transitions which led to the creation of values or threads. It is required in 
order to differentiate recursive instances of a value or thread. All threads with the same 
program point have an environment defined on the same domain, called the program 
point interface. 

We will describe some primitives that allow us to define the non standard semantics, 
then, briefly, we show how to compute transitions in this semantics. 

3.1 Partial interactions 

We associate to each program point a partial interaction which defines how threads 
related to this program point can interact with others. We also define the set of variables 
associated to each thread, constituting its environment, according to its program point. 
Here, in CAP, partial interactions can represent a syntactically defined actor, a dynamic 



Fig. 1. Transition rule of CAP standard semantics 
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Fig. 2. Congruence relation of CAP standard semantics 



one (an actor whose behavior is defined by a variable) and a particular behavior of an 
actor or a sent message. 

We thus define the set of partial interactions names = {static_actor„, behaviorn, 
messagCn | n € N} U {dynamic _act or} and their arities as foUows: 

Art = {static_actor„ t-^ {2,n),dynamic_actor {2,0), behaviorn 1— > (l,n + 2), 

messagCn (« + 2,0)} 

Partial interaction arities define the number of parameters and the number of bound 
variables. 

The partial interaction dynamic_actor denotes a thread representing an actor. It is 
consumed when interacting. It has only two parameters: its name and set of behaviors. 
It binds no variables. 

Both partial interaction static_actor„ and behavior,, denote a particular behavior of 
an actor. The first one is associated to an address when the second one is alone and 
can be used with a dynamic actor. The second one acts as a definition and stays in 
the configuration when used, whereas the first one is deleted. They are parametrized 
by their message labels and binds « + 2 variables, the variables under the ^ operator 
expressing reflexivity as well as the parameters of the message it can handle. The first 
one is also parametrized by its actor's name. 

Finally the partial interaction messagen represents the message that is sent to a par- 
ticular address (actor). So it has n + 2 parameters: one for the address, one for the 
message name and n for the variables of this message. It is consumed when interacting. 

We associate to each partial interaction a type denoting whether such a partial inter- 
action is consumed or not when interacting. 

3.2 Abstract syntax extraction 

We now define the syntax extraction function that takes a CAP term describing the 
initial state of an agents' system in the standard syntax and extracts its abstract syntax. 

We map each program point labeled / G to a set of partial interaction and to an 
interface. 

A partial interaction pi is given by a tuple {s, {parameteri) , {boundi) , constraints, con- 
tinuation) where s € ,e/ is a partial interaction name, {m,n)= Ari{s) its arity, {parameteri) 
e y" its finite sequence of variables (X,), {boundi) G its finite sequence of distinct 



variables (Yi), constraints C {vov' \ (v,v') S 1^^,o € {=,7^}} its synchronization con- 
straints and finally continuation G p{^p x [Y its syntactic continuation. We 
wiU check constraints defined in the set constrains about thread environment with the 
use of the sequence {parameten), then we will use both sequences [parameteri) and 
{boundi) to compute value passing, finally we will deal with the set continuation to 
determine which threads have to be inserted in the system. 

- the label of a program point a >' [m^i{xi) = tl,{ei,Si)Ci -'-'"] is associated to the 
interface {a} and to the following set of partial interactions: 

{static_actor„, [a, mi], [ei,ii,fi],P(Ci,0)) 
{static_actorn, [a,m2], [e2,S2,X2],^{C2,i>)) 



[{(■ 



static_actorn , [a , mm] , [em ,Sm,Xm\ 



,P(Cm,0))} 



- the label of a program point a >' x is associated to the interface {a,x} and to the 
following set of partial interactions: ^{dynamic _act or, [a,x],0,0)| 

- the label of a program point a <' m{P) is associated to the interface {a} U J y (P) 
and to the following set of partial interactions: ^{message„, [a;m;P], 0,0) | 

- the label of a program point Z, corresponding to a particular behavior of an actor 
i.e. m-ix) = C,{ei,Si)Ci is associated to the interface f l^{Ci) \ {e,-,s,} and to the 
following set of partial interactions: ^{behavior„, [m,], [e;,s,,x], P(Ci,0))| 

Finally, the syntax extraction function P is defined inductively over the standard syntax 
of the syntactic continuation, as follows: 



P((va«)C,£,) 

m\\c2,Es) 

^{a>' [m'iixi) =i;{ei,Si)Cr''-%Es) 
P(a >'B,Es) 
^{a<'m{P),Es) 



P(C,£,[aH^a]) 
{0} 

|3(Ci,£,)U|3(C2,£,) 
{(/,£,)} UU=i,...,„ {(/;,£.)} 

{{mm 
{{{i,Esm 



The initial state for a term ^ is described by initg, a set of potential continuations 
in pipi^p X {f^^))) defined as P(^,0). 



3.3 Formal Rules 

We now define the formal rules that drive the interaction between threads. In the case 
of CAP, we have two rules that describe an actor handUng a message, depending on the 
kind of actor we have, a static or a dynamic one. 

In the following, the i-th parameter, the 7-th bounded variable, and the identity of 
the A:-th partial interaction are respectively denoted by X*, Yj and We define the 



endomorphism behavior_set on the set x ^ as follows: {p,m) ^ {p\m) where 
p is a behavior program point and p' is the program point where p has been syn- 
tactically defined. As an example, in the term v°'a,a >^ [m^O = ^{e,s)C], we have 
behavior _set {2, m) = (l,m). 

Communication with a syntactic defined actor. The first rule needs two threads, the first 
one must denote a partial interaction static_actor when the second one must denote a 
partial interaction message„. We both check that the actor's address (X/) is equal to the 
message's receiver {X^) and that the actor behavior label (Zj) is equal to the message 
label {X^). 

We then define v_passing that describe the value passing due to both the ^ operator 
and message handhng. 

static JranSn = {2, components, compatibility,v _j)assing) 

where 

( I static_actor„, - ., .,. (X}=X?; 

1. components = s r, 2. compatibility = < „i _ „2. 

I ^ I ^ message fi i ^2 — 2, * 

(Y.'^Xl- 
3. v_passing = < <— 

il^-V2-^?+2,V»Gll;nl; 

Communication with a dynamic actor. The second rule needs three threads: the first 
one must denote a partial interaction behavior„, the second one a partial interaction 
dynamic _actor and the third one a message message„. We check the equality between 
actor's address (Xf) and receiver (Xf), behavior label (X}) and message label With 
the behavior_set function we check the link between the behavior and the actor. The 
value passing is defined in the same way as in the first rule. 

dynamic JranSn = {3, components, compatibility, v _passing) 

where 



1. components = < 2 1-^ dynamic _act or, 2. compatibility = < behavior _set{I^) =X|, 



3. v_passing ■ 




behavior„, ( Xf ~ X^ 



message„ I Xj = ; 



I^,2-^?+2,VjG[l;nl; 



3.4 Operational semantics 

We now briefly describe how to use the preceding definitions to express in the non 
standard syntax both an initial term and the computation of a transition according to a 
formal rule. 

Initial configurations are obtained by launching a continuation in inits with an empty 
marker and an empty environment. That means inserting in an empty configuration, one 



thread for each pair {p,Es ) in ^ {initg ) where each value in Eg is associated with an empty 
marker. We focus now on the interaction computation according to one of the two rules. 
First of all, we have to find some correct interaction. It means that we have to find some 
threads in the current configuration that can be associated to the right partial interaction 
according to the matching formal rule. Then we check that their interface satisfies the 
synchronization constraints. Thus we can compute the interaction: 

- we remove interacting threads according to the type of their exhibited partial inter- 
action; 

- we choose a syntactic continuation for each thread; 

- we compute dynamic data for each of these continuations: 

• we compute the marker; 

• we take into account name passing; 

• we create fresh variables and associate them with the correct values; 

• we restrict the environment according to the interface associated with the pro- 
gram point. 



3.5 Correspondence 

Theorem 1 (correspondence) CAP standard semantics and its non standard seman- 
tics are in strong bisimulation 

Proof. The proof can be found at the first author's web page, www.enseeiht.fr/ garoche. 



3.6 Example 

To illustrate the use of the non standard semantics, we will compute the first transition 
of the example given in section 2. 
The initial configuration^ is: 



(l,e, [a a,e]) (2,e, [a ^ a,e] ) (4,e,Q) (6,e, 



fl 1-^ a,e 
b ^ P,e 

(7,e,[Z7H^p,e]) (8,e,[]) (10,e, ^ p,e'] ) 



) 



At this point, the only possible transition is labeled by 1 , 6 and corresponds to the 
staticjransn rule. Program point 1 is able to exhibit the two following partial inter- 

{< {static_actor„, [a,m\,[e,s],^{a >^ s,<d)) >, 
> ^ ) } when the program 

< {static_actor„, [a, send], [e,s,x],^{x <^ beh{s),%)) > 

point 6 exhibits the only partial interaction: 

I {messagen , [a , send , fo] , , 0) | 



' We can notice the absence of threads at program points 3, 5 and 9 which correspond to sub- 
terms. There are not present in the initial configuration. 



We choose the first partial interaction for 1. We first check synchronization con- 
straints. We needthatXj =Xl andXj = Xl . So (a,e) = (a,8) and both message share 
the same label send. We can now compute value passing, thread launching and remov- 
ing. We have to remove interacting threads and to add threads in P(x beh{s),d) 
with their environment updated by value passing. Value passing gives the value of 
e, s and x, we have respectively, (oc,e), (1,e) and (P,e). Thus the launched thread is 
X 1-^ P,e 
s t-* l,e 
We obtain the new configuration: 



(5,8, 



(2,e,[aH^a,e]) (4,e,[]) (5,e, 



1,8 



) 



(7,8,[fe^P,8]) (8,8,0) (10,8,[fe^P,8]) 

We recall that when computing a transition using the dynamic JranSn rule, new 
launched threads are associated to a new marker. 



4 Abstract semantics 

In order to ensure properties on all the possible execution of the non standard semantics, 
we rely on the abstract interpretation approach which combines in a single one all the 
possible executions. 



4.1 Abstract Interpretation 

Abstract interpretation [10] is a theory of discrete approximation of semantics. A fun- 
damental aspect of this theory is that every semantics can be expressed as fixed points 
of monotonic operators on complete partial orders. A concrete semantics is defined by 
a tuple (5,C,_L,u,T,n). Following [11], an abstract semantics is defined by a pre- 
ordered set (5*, C), an abstract iteration basis _L*, a concretization function y : 5* — > 5 
and an abstract semantics function F*. 



Abstract interpretation of mobile systems. We approximate here the mobile systems' 
semantics as described in [15,29]. The collecting semantics of a configuration is 
defined as the least fixed point of the complete join morphism F: 

F(X) = ({8} X "^o) U { {u.'k,C')\3C e (m,C) G X and C ^ C } 

An abstraction ('^*, C*, U*, _L*, y", Cq , V) in this framework must define as usual 
a pre-order, a join operator, a bottom element, a widening operator (when abstract do- 
mains are infinite) as well as: 

- the initial abstract configuration C* E with {e} x%C y(C^) 

- the abstract transition relation ~^ G p('^* x E x 'rf^) such that: 

vc* G '^*,v(m,c) g y(c*),v^ G z,vc' G ^, 



C^C ^ 3C'* e 'i*, (C# ^ C'#) and (mA,C') g y(C'#) 

Such an abstract transition computes all the concrete transitions labeled X from all 
possible C represented by C*. 

The abstract counterpart of the F function is the abstract function F* defined as: 
F*(C#) = U* {{C* I 3?i e Z,C* C'*} U {(^;C*}) 

4.2 Abstract Domains 

An element of an abstract domain expresses the set of invariant properties of a set of 
terms. We project the initial term into an abstract element to describe its properties. 
Then we use an abstract counterpart of the transition rules to obtain the set of valid 
properties when applying the transition rule to all elements of the initial set. Then we 
compute the union of both abstract elements, to only keep the set of properties which 
are vaUd before and after the transition. We repeat these steps until a fixed point is 
reached. The use of the union and the widening functions guarantees the monotony of 
the transition and thus the existence of the fixed point. Finally, we obtain an abstract el- 
ement describing the set of valid properties in all possible evolutions of the initial term. 
It is a post fixed point of the collecting semantics' least fixed point. Our abstractions are 
sound counterparts of the non standard semantics. 

In order to avoid a too coarse approximation of the collecting semantics, we need, at 
least, to use a good abstraction of the control flow. We associate to each program point 
an abstract element describing its set of values and markers. But, most of our properties 
can be expressed in terms of occurrence counting. We also need to approximate config- 
urations globally. Therefore, we use, as an abstract domain, the cartesian product of an 
abstract domain to approximate non uniform control flow information in conjunction 
with a domain to approximate the occurrence of threads in configurations. 

Generic abstractions. In this section, we will briefly describe the two abstract do- 
mains defined, by Feret, respectively in [13J and [12] that are used to approximate the 
non standard semantics of CAP. Their operational semantics is then given in Figs. 3(a) 
and 3(b). 

Control Flow Abstract Domain. This abstract domain approximates variable values of 
thread environments as well as their marker for a given configuration. It is parametrized 
by an abstract domain called an Atom Domain. We associate to each program point 
an atom which describes the values of both variables and markers of the threads that 
can be associated with this program point. When computing an interaction, we merge 
the interacting atoms associated to the interacting threads (primitive reagents^) and 
add synchronization constraints (primitive sync^). If they are satisfiable, the interaction 
is possible. We then compute the value passing and the marker computation (function 
marker _value). Finally, we launch new threads (primitive launch^) and update the atom 
of each program point by computing its union with the appropriate resulting atom. 

In this domain, we only focus on values, so we completely abstract away occur- 
rences of threads and thus deletion of interacting threads. 



Let C* be an abstract configuration, let {pk)i<k<n G be a tuple of program points label and 
{pik)i<k<n = i^kj [pammeterk), {bdk),constraintSk,continuationk) be a tuple of partial interac- 
tions. 

We define mol by reagents* {{pk), (parameterk^i), {constraintSk),Cf). 
When 

e |l;n],p(,t £ interaction{pk) ; 
mol ^ 
Then 

;new_threads} 

Where 

1. mol' = marker_value{{pk)k-moI . {hclk.i jk.l- {p'^''<i^^tB^k,l)k,h v_passing) 

2. new_threads = launch^{{pk,continuationsk)k,mol'). 

(a) Abstract semantics for control flow approximation. 

We define the tuple t € so that be the occurrence of v in (p*:) i<jt<„. 
When 

\/k € |l;n],p(j(. e interaction{pk) ; SYNC jy^^ (f ,C*) ± jy^^ 
Then 

C^^^^#SYNC {t,C*) +* Transition +* Launched — * Consumed 
Where 

1. Transition — l^yYy (pi); 

2. Launched = Z* (^{^^ (continuation^))^) ; 

3. Consumed = £*(1^^^ (P/fc))/te{/(:'| 

(b) Abstract semantics for occurrence counting. 

Fig. 3. Abstract operational semantics 



The Atom Domain we use is a reduced product of four domains. The first two 
represent equality and disequality among values and marker using graphs, the third one 
approximates the shape of markers and values with an automaton and the fourth one 
approximates the relationship between occurrences of letters in Parikh's vectors [25] 
associated to each value and marker. 



Occurrence Counting Abstract Domain. In this domain, we count both threads associ- 
ated to a particular program point and transition label, the set of which is denoted by Yc- 
We first approximate the non standard semantics by the domain associating to each 
program point its threads occurrence in the configuration and to each transition label, its 
occurrence in the word that leads to the configuration. At the level of the collecting se- 
mantics, we obtain an element in p(N^<^). We then abstract such a domain by a domain 
jVy^ which is a reduced product between the domain of intervals indexed by and 
the domain of affine equalities [21] constructed over %. When computing a transition, 
we check that the occurrences of interacting threads are sufficient to allow it (primitive 
SYNC .yV^^)- If we do not obtain the bottom element of our abstract domain, i.e. the syn- 
chronization constraint is satisfiable, we add (primitive +*) the new transition label, the 
launched threads (primitives P* and 1?) and remove (primitive — *) consumed threads. 



5 Properties 



The abstract semantics computes an approximation of all the execution in the non stan- 
dard one. Its result can then be used in order to check many different properties. In this 
section, we describe interesting properties and how to observe them in the fixed point 
of the analysis. 

5.1 Linearity 

Linearity is a property that expresses the fact that all actors in each possible configu- 
ration are bound to different addresses. It can be expressed as in 7t-calculus when each 
process listens to at most one channel. It is a useful property to map addresses to re- 
sources. 

Our analysis is able to prove that a term, without recursive name definitions, i.e. with- 
out a V operator inside a behavior continuation, will be linear in all the possible config- 
urations it will take. We can observe such a property with both the control flow domain 
and the occurrence counting domain. We first determine with the control flow the up- 
per set of program points representing actors that can be associated with each address. 
Then we check in the occurrence counting domain that each of those program points 
is mapped to at most one thread in each configuration (within the interval domain) 
and, moreover, that program points that can be associated with the same address are 
in mutual exclusion (with the global numerical domain). The mutual exclusion prop- 
erty is observed by exhibiting a constraint from the global numerical domain. Such a 
constraint must be a linear combination Ex, + Hkj *yj — \ with {xi} the set of program 
points in mutual exclusion and {kj} a set of positive or null coefficients. Whether such 
a constraint can be generated by the set of constraints describing the affine space of the 
global numerical domain then the {xi} program points are in mutual exclusion but they 
do not have to be present in every configuration of the system. 

In the following example, we can automaticaUy determine that the foUowing term 
satisfies the linearity property. 

jg„j4:iO;il(^) = ^^-P'^l beh{s))] 

II b >6:I0;il [teh'^-mi(^jc) = Ue.s){e >8:I0;1I x)] 
II fl ^en£/(fo) ||fo<i":PWlm() 

All the actors are associated with the interval |0; IJ. The only actor that can be 
associated to address a is 1 and others (3,6 and 8) can be associated with address b. 
Then the constraint P3 + pe + P8 — ^ can be observed in the global numerical part of 
the post fixed point of the analysis. We can notice that we have a stronger property: 
there is exactly one actor on the address b in every configuration of this term. 

5.2 Bounded resources 

As CAP is an asynchronous calculus, when a message is sent we cannot ensure that 
it will be handled. With this property, we want to determine if the system grows in- 
finitely; if the system creates more messages than it can handle. Our analysis is able 



to infer such a property. We first check which message can have an unbounded num- 
ber of occurrences. Then we check in the global numerical invariants of the system a 
constraint between the number of occurrences of this message and the number of oc- 
currences of a transition labeled with the same message label. When such a constraint 
can be found, we can say that this message will be in the system an unbounded number 
of times, but it will be handled the same number of times. The system size is constant, 
it does not diverge. 

In the following example, our analysis is able to find that at most one message is 
present in the system: program points 3, 7 and 9 associated with interval [0; 1]. The 
system described by this term is bounded. Furthermore, we have the constraint ps + 
P7+P9 = 1- 

va«,vZ7p, a >i^P'il = C(e,i)(^ pongQ \\ e >4:I0;iI ,)] 

II b >5:I0;il = i;{e,s){a <^^P;iI pingQ \\ e >8^P;iI s)] 

||a<9:10;il pingQ 

In addition, we can also detect whether a system does not generate an unbounded 
number of actor present at the same time in a given configuration. 

va^a >i^P;iI [m2^Ii;il() = l^{e,s){vb^b >3:I0;il s\\b <4:I0;iI ^Q)] || a <5:I0;iI „q 

In the preceding example, we automatically detect that the number of threads asso- 
ciated to program point 3 hes in |0; 1|. 

5.3 Unreachable behaviors 

We are interested in determining the subset of behaviors that are really used for each set 
of behaviors. Due to its high-order capabihty, CAP allows to send the set of behaviors 
syntactically associated to an actor to other actors. Therefore the use of the behavior's 
set depends highly on the messages exchanged. 

In the following example, all the behavior branches of the behavior syntactically 
defined at program point 1 are used. We check such a property by checking that each 
label of transition is present at least once or its continuation has been launched. I.e. Vf G 
%,Inter{t) ^ [[0;0] where Inter is the function that maps each element of % to its 
image in interval part of the analysis post fixed point. 

Va«,foP,c'i',a>i [ml{)=:,{e,s){b ni{s) \\ b <]'^ mi{c)) , 
m\{dest) = t,{e,s){dest wiO), 

II Z7 [>8 [n\{self) = i;{e,s){e t>^^ self I| c <" niiself))] 

\\c>'^n\\self)=l^ie,s){e>'^self)] 

II a wo() 

We can use such an analysis to clean the term with garbage collecting like mecha- 
nisms. 



6 Conclusion 



We have adapted the framework of Feret [15] to deal with a higher order process 
calculus modeling actor languages. With such a framework, we are able to analyze CAP 
terms without any restriction about the kind of values sent within messages: we can now 
handle behavior passing, which was not able with our previous type based analysis. In 
contrary to our aforementioned analyses about actor's calculus, we are able to easily 
count occurrences of both actors and messages. Therefore, most of the properties we 
obtain are related to occurrence counting. We can detect whether the number of actors 
and messages is finite, whether there is dead code and whether the message queues are 
bounded. We also have the linearity property under certain restrictions. 

To go further, we need another abstraction which will spht thread's information into 
computation units representing the recursive instances of the same thread. Such an ab- 
stract domain will allow us to deal with linearity in the general case as well as handling 
more properties. In fact the most interesting property with an asynchronous process 
calculus with non uniform behavior, is the detection of orphan messages, i.e. stuck- 
freeness. An orphan is a message which may not be handled by its target in some exe- 
cution path. We distinguish two kinds of orphan: safety ones and hveness ones. Safety 
orphans occur when all future behaviors of the target on a given execution path cannot 
handle such a message. On the contrary, Hveness orphans occur when one of the target 
behaviors in each execution paths knows how to handle such a message but the target is 
deadlocked and will never assume the corresponding behavior. We advocate that with 
this new abstract domain we will be able to detect both kinds of orphans. We also want 
to define a generic abstract domain dedicated to the data-flow like analyses provided by 
type systems. Such an abstract domain can be useful to automatically build domains to 
observe properties for which we already have a type system. 
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